The present invention relates to distributed processing systems and, in particular, computer software in distributed processing systems.
There are several types of distributed processing systems. Generally, a distributed processing system includes a plurality of processing devices, such as two computers coupled to a communication medium. Communication mediums may include wired mediums, wireless mediums, or combinations thereof, such as an Ethernet local area network or a cellular network. In a distributed processing system, at least one processing device may transfer information on the communication medium to another processing device.
Client/server architecture 110 illustrated in FIG. 1a is one type of distributed processing system. Client/server architecture 110 includes at least two processing devices, illustrated as client 105 and application server 103. Additional clients may also be coupled to communication medium 104, such as client 108.
Typically, server 103 hosts business logic and/or coordinates transactions in providing a service to another processing device, such as client 103 and/or client 108. Application server 103 is typically programmed with software for providing a service. The software may be programmed using a variety of programming models, such as Enterprise Java(trademark) Bean (xe2x80x9cEJBxe2x80x9d) 100b as illustrated in FIGS. 1a-b. The service may include, for example, retrieving and transferring data from a database, providing an image and/or calculating an equation. For example, server 103 may retrieve data from database 101a in persistent storage 101 over communication medium 102 in response to a request from client 105. Application server 103 then may transfer the requested data over communication medium 104 to client 105.
A client is a processing device which utilizes a service from a server and may request the service. Often a user 106 interacts with client 106 and may cause client 105 to request service over a communication medium 104 from application server 103. A client often handles direct interactions with end users, such as accepting requests and displaying results.
A variety of different types of software may be used to program application server 103 and/or client 105. One programming language is the Java(trademark) programming language. Java(trademark) application object code is loaded into a Java(trademark) virtual machine (xe2x80x9cJVMxe2x80x9d). A JVM is a program loaded onto a processing device which emulates a particular machine or processing device. More information on the Java(trademark) programming language may be obtained at http://www.javasoft.com, which is incorporated by reference herein.
FIG. 1b illustrates several Java(trademark) Enterprise Application Programming Interfaces (xe2x80x9cAPIsxe2x80x9d) 100 that allow Java(trademark) application code to remain independent from underlying transaction systems, data-bases and network infrastructure. Java(trademark) Enterprise APIs 100 include, for example, remote method invocation (xe2x80x9cRMIxe2x80x9d) 100a, EJBs 100b, and Java(trademark) Naming and Directory Interface (JNDI) 100c. 
RMI 100a is a distributed programming model often used in peer-to-peer architecture described below. In particular, a set of classes and interfaces enables one Java(trademark) object to call the public method of another Java(trademark) object running on a different JVM.
An instance of EJB 100b is typically used in a client/server architecture described above. An instance of EJB 100b is a software component or a reusable pre-built piece of encapsulated application code that can be combined with other components. Typically, an instance of EJB 100b contains business logic. An EJB 100b instance stored on server 103 typically manages persistence, transactions, concurrency, threading, and security.
JNDI 100c provides directory and naming functions to Java(trademark) software applications.
Client/server architecture 110 has many disadvantages. First, architecture 110 does not scale well because server 103 has to handle many connections. In other words, the number of clients which may be added to server 103 is limited. In addition, adding twice as many processing devices (clients) does not necessarily provide you with twice as much performance. Second, it is difficult to maintain application code on clients 105 and 108. Third, architecture 110 is susceptible to system failures or a single point of failure. If server 101 fails and a backup is not available, client 105 will not be able to obtain the service.
FIG. 1c illustrates a multi-tier architecture 160. Clients 151, 152 manage direct interactions with end users, accepting requests and display results. Application server 153 hosts the application code, coordinates communications, synchronizations, and transactions. Database server 154 and portable storage device 155 provides durable transactional management of the data.
Multi-tier architecture 160 has similar client/server architecture 110 disadvantages described above.
FIG. 2 illustrates peer-to-peer architecture 214. Processing devices 216, 217 and 218 are coupled to communication medium 213. Processing devices 216, 217, and 218 include network software 210a, 210b, and 210c for communicating over medium 213. Typically, each processing device in a peer-to-peer architecture has similar processing capabilities and applications. Examples of peer-to-peer program models include Common Object Request Broker Architecture (xe2x80x9cCORBAxe2x80x9d) and Distributed Object Component Model (xe2x80x9cDCOMxe2x80x9d) architecture.
In a platform specific distributed processing system, each processing device may run the same operating system. This allows the use of proprietary hardware, such as shared disks, multi-tailed disks, and high speed interconnects, for communicating between processing devices. Examples of platform-specific distributed processing systems include IBM(copyright) Corporation""s S/390(copyright) Parallel Sysplex(copyright), Compaq""s Tandem Division Himalaya servers, Compaq""s Digital Equipment Corporation(trademark) (DEC(trademark)) Division OpenVMS(trademark) Cluster software, and Microsoft(copyright) Corporation Windows NT(copyright) cluster services (Wolfpack).
FIG. 2b illustrates a transaction processing (TP) architecture 220. In particular, TP architecture 220 illustrates a BEA(copyright) Systems, Inc. TUXEDO(copyright) architecture. TP monitor 224 is coupled to processing devices ATM 221, PC 222, and TP monitor 223 by communication medium 280, 281, and 282, respectively. ATM 221 may be an automated teller machine, PC 222 may be a personal computer, and TP monitor 223 may be another transaction processor monitor. TP monitor 224 is coupled to back-end servers 225, 226, and 227 by communication mediums 283, 284, and 285. Server 225 is coupled to persistent storage device 287, storing database 289, by communication medium 286. TP monitor 224 includes a workflow controller 224a for routing service requests from processing devices, such as ATM 221, PC 222, or TP monitor 223, to various servers such as server 225, 226 and 227. Work flow controller 224a enables (1) workload balancing between servers, (2) limited scalability or allowing for additional servers and/or clients, (3) fault tolerance of redundant backend servers (or a service request may be sent by a workflow controller to a server which has not failed), and (4) session concentration to limit the number of simultaneous connections to back-end servers. Examples of other transaction processing architectures include IBM(copyright) Corporation""s CICS(copyright), Compaq""s Tandem Division Pathway/Ford/TS, Compaq""s DEC(trademark) ACMS, and Transarc Corporation""s Encina.
TP architecture 220 also has many disadvantages. First, a failure of a single processing device or TP monitor 224 may render the network inoperable. Second, the scalability or number of processing devices (both servers and clients) coupled to TP monitor 224 may be limited by TP monitor 224 hardware and software. Third, flexibility in routing a client request to a server is limited. For example, if communication medium 280 is inoperable, but communication medium 290 becomes available, ATM 221 typically may not request service directly from server 225 over communication medium 290 and must access TP monitor 224. Fourth, a client typically does not know the state of a back-end server or other processing device. Fifth, no industry standard software or APIs are used for load balancing. And sixth, a client typically may not select a particular server even if the client has relevant information which would enable efficient service.
Therefore, it is desirable to provide a distributed processing system and, in particular, distributed processing system software that has the advantages of the prior art distributed processing systems without the inherent disadvantages. The software should allow for industry standard APIs which are typically used in either client/server, multi-tier, or peer-to-peer distributed processing systems. The software should support a variety of computer programming models. Further, the software should enable (1) enhanced fault tolerance, (2) efficient scalability, (3) effective load balancing, and (4) session concentration control. The improved computer software should allow for rerouting or network reconfiguration. Also, the computer software should allow for the determination of the state of a processing device.
An improved distributed processing system is provided and, in particular, computer software for a distributed processing system is provided. The computer software improves the fault tolerance of the distributed processing system as well as enables efficient scalability. The computer software allows for efficient load balancing and session concentration. The computer software supports rerouting or reconfiguration of a computer network. The computer software supports a variety of computer programming models and allows for the use of industry standard APIs that are used in both client/server and peer-to-peer distributed processing architectures. The computer software enables a determination of the state of a server or other processing device. The computer software also supports message forwarding under a variety of circumstances, including a security model.
According to one aspect of the present invention, a distributed processing system comprises a communication medium coupled to a first processing device and a second processing device. The first processing device includes a first software program emulating a processing device (xe2x80x9cJVM1xe2x80x9d) including a first kernel software layer having a data structure (xe2x80x9cRJVM1xe2x80x9d). The second processing device includes a first software program emulating a processing device (xe2x80x9cJVM2xe2x80x9d) including a first kernel software layer having a data structure (xe2x80x9cRJVM2xe2x80x9d). A message from the first processing device is transferred to the second processing device through the first kernel software layer and the first software program in the first processing device to the first kernel software layer and the first software program in the second processing device.
According to another aspect of the present invention, the first software program in the first processing device is a Java(trademark) virtual machine (xe2x80x9cJVMxe2x80x9d) and the data structure in the first processing device is a remote Java(trademark) virtual machine (xe2x80x9cRJVMxe2x80x9d). Similarly, the first software program in the second processing device is a JVM and the data structure in the second processing device is a RJVM. The RJVM in the second processing device corresponds to the JVM in the first processing device.
According to another aspect of the present invention, the RJVM in the first processing device includes a socket manager software component, a thread manager software component, a message routing software component, a message compression software component, and/or a peer-gone detection software component.
According to another aspect of the present invention, the first processing device communicates with the second processing device using a protocol selected from the group consisting of Transmission Control Protocol (xe2x80x9cTCPxe2x80x9d), Secure Sockets Layer (xe2x80x9cSSLxe2x80x9d), Hypertext Transport Protocol (xe2x80x9cHTTPxe2x80x9d) tunneling, and Internet InterORB Protocol (xe2x80x9cIIOPxe2x80x9d) tunneling.
According to another aspect of the present invention, the first processing device includes memory storage for a Java(trademark) application.
According to another aspect of the present invention, the first processing device is a peer of the second processing device. Also, the first processing device is a server and the second processing device is a client.
According to another aspect of the present invention, a second communication medium is coupled to the second processing device. A third processing device is coupled to the second communication medium. The third processing device includes a first software program emulating a processing device (xe2x80x9cJVM3xe2x80x9d), including a kernel software layer having a first data structure (xe2x80x9cRJVM1xe2x80x9d), and a second data structure (xe2x80x9cRJVM2xe2x80x9d).
According to still another aspect of the present invention, the first processing device includes a stub having a replica-handler software component. The replica-handler software component includes a load balancing software component and a failover software component.
According to another aspect of the present invention, the first processing device includes an Enterprise Java(trademark) Bean object.
According to still another aspect of the present invention, the first processing device includes a naming tree having a pool of stubs stored at a node of the tree and the second processing device includes a duplicate of the naming tree.
According to still another aspect of the present invention, the first processing device includes an application program coded in a stateless program model and the application program includes a stateless session bean.
According to still another aspect of the present invention, the first processing device includes an application program coded in a stateless factory program model and the application program includes a stateful session bean.
According to still another aspect of the present invention, the first processing device includes an application program coded in a stateful program model and the application program includes an entity session bean.
According to still another aspect of the present invention, an article of manufacture including an information storage medium is provided. The article of manufacture comprises a first set of digital information for transferring a message from a RJVM in a first processing device to a RJVM in a second processing device.
According to another aspect of the present invention, the article of manufacture comprises a first set of digital information, including a stub having a load balancing software program for selecting a service provider from a plurality of service providers.
According to another aspect of the present invention, the stub has a failover software component for removing a failed service provider from the plurality of service providers.
According to another aspect of the present invention, the load balancing software component selects a service provider based on an affinity for a particular service provider.
According to another aspect of the present invention, the load balancing software component selects a service provider in a round robin manner.
According to another aspect of the present invention, the load balancing software component randomly selects a service provider.
According to another aspect of the present invention, the load balancing software component selects a service provider from the plurality of service providers based upon the load of each service provider.
According to another aspect of the present invention, the load balancing software component selects a service provider from the plurality of service providers based upon the data type requested.
According to another aspect of the present invention, the load balancing software component selects a service provider from the plurality of service providers based upon the closest physical service provider.
According to another aspect of the present invention, the load balancing software component selects a service provider from the plurality of service providers based upon a time period in which each service provider responds.
According to another aspect of the present invention, the article of manufacture comprises a first set of digital information, including an Enterprise Java(trademark) Bean object for selecting a service provider from a plurality of service providers.
According to another aspect of the present invention, a stub is stored in a processing device in a distributed processing system. The stub includes a method comprising the steps of obtaining a list of service providers and selecting a service provider from the list of service providers.
According to another aspect of the present invention, the method further includes removing a failed service provider from the list of service providers.
According to still another aspect of the present invention, an apparatus comprises a communication medium coupled to a first processing device and a second processing device. The first processing device stores a naming tree including a remote method invocation (xe2x80x9cRMIxe2x80x9d) stub for accessing a service provider. The second processing device has a duplicate naming tree and the service provider.
According to another aspect of the present invention, the naming tree has a node including a service pool of current service providers.
According to another aspect of the present invention, the service pool includes a stub.
According to another aspect of the present invention, a distributed processing system comprises a first computer coupled to a second computer. The first computer has a naming tree, including a remote invocation stub for accessing a service provider. The second computer has a replicated naming tree and the service provider.
According to another aspect of the present invention, a distributed processing system comprising a first processing device coupled to a second processing device is provided. The first processing device has a JVM and a first kernel software layer including a first RJVM. The second processing device includes a first JVM and a first kernel software layer including a second RJVM. A message may be transferred from the first processing device to the second processing device when there is not a socket available between the first JVM and the second JVM.
According to another aspect of the present invention, the first processing device is running under an applet security model, behind a firewall or is a client, and the second processing device is also a client.
Other aspects and advantages of the present invention can be seen upon review of the figures, the detailed description, and the claims which follow.